[Astuce] Eviter d’inclure l’assembly du projet dans son package

SharePoint 2010

Aujourd’hui c’est une astuce très courte mais qui montre bien tout le soin apporté aux outils de développement.

Le contexte

Vous devez réaliser un package de déploiement (WSP pour ceux qui n’auraient pas suivi ;)) composé uniquement d’éléments descriptifs tels que :

  • fichiers XML de fonctionnalités,
  • des ressources “Web” tels que des images, fichiers javascript, feuilles de style etc… à mettre dans le “14” (répertoires LAYOUTS, IMAGES, dans un module, …)
  • des ressources de traductions (resx)
  • ….

Bref, beaucoup de choses mais sans une seule ligne de code et sans assembly.

Avant

Auparavant, i.e. avec la version 2007, en tant qu’utilisateur de WSPBuilder, je faisais un projet de type bibliothèque de classes dans lequel je créais la hiérarchie du “12” et je changeais le répertoire de sortie pour générer ma DLL quelque part où elle ne m’ennuierait pas pour le packaging, ou bien j’excluais le fichier dans la configuration de WSPBuilder.

Bref, forcément, il y avait des fois où je zappais cette étape et je nettoyais après-coup lorsque je pensais à jeter un oeil sur le manifeste de ma solution (une bonne pratique à garder lorsqu’on automatise la génération du package).

Maintenant (version 2010)

Avec les outils de développements fournis dans Visual Studio 2010, on peut tranquillement créer son projet vide SharePoint et y ajouter les éléments à déployer comme par exemple dans ce projet où j’ai simplement mis quelques images :

Projet sans code

Je génère le package via le menu contextuel :

Génération du package de déploiement

Et je me rends dans le répertoire de sortie (“bin\debug” ici) où se retrouve mon fichier WSP. En le renommant avec l’extension CAB je peux de suite l’ouvrir et consulter son contenu :

Contenu du package (fichier CAB)

On y voit l’assembly qui a été automatiquement générée mais qui est vide et ne me sert à rien, sauf à m’encombrer d’une dll à placer quelque part…

La solution est très simple : cliquez sur le projet et affichez les propriétés :

Propriété du projet : déploiement de l'assembly dans le package

Vous pouvez y voir l’option “Include Assembly In Package”, actuellement à “True” (vous pouvez en profiter pour remarquer juste au dessus la cible de l’assembly,au choix le GAC ou le répertoire Bin de l’application web).

Reste à changer la valeur à “False”, relancer le package et vérifier le résultat attendu :

Package sans assembly

L’assembly n’y est plus !

Simple n’est-il pas ? Ca résume la philosophie de ces nouveaux outils : simplicité, efficacité, mais sans brider la puissance de la bête !

Gat, packageur fou

 

Commentaires

Le 27 Nov 2009 02:35, Henri a dit:

Salut Gat,

Quel est l'intérêt de ne pas inclure la DLL dans les packages ? Du coup, tu la déploies dans le GAC manuellement (ou dans le bin) ? Il y a des bonnes pratiques à suivre?
Merci d'avance pour tes conseils !
Henri

Le 30 Nov 2009 11:59, Gat a dit:

Henri : en fait, ça dépend de ce que tu mets dans ton projet. Mais parfois, ce ne sont que des définitions XML et donc 0 code utile.
De fait, tu vas te retrouver à embarquer une DLL générée par défaut par le projet mais qui ne contient rien. Ca signifie aussi qu'au déploiement tu risques d'avoir un warning si tu mets dans le GAC ou à choisir dans quelle Web Application tu déploies ta DLL (si dans le Bin).
Bref, ça n'est pas un cas fréquent, mais suffisamment courant pour l'avoir fait pas mal de fois auparavant.

Le 02 Dec 2009 01:37, Henri a dit:

Ok ! Merci Gat. J'avais pas saisi ce cas plus ou moins particulier !

Laisser un commentaire





Validation Image CAPTCHA